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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In re Patent Application of: 
Nicholas A. John, Peach 

Application No.: 09/576,223 Confirmation No.: 2229 

Filed: May 22, 2000 Art Unit: 2131 

For: ELECTRONIC CONTRACTS Examiner: E. H. Quinones 

APPEAL BRIEF UNDER 37 C.F.R. § 1.192 

MS Appeal Brief - Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Dear Sir: 

The undersigned submits the brief in connection with the above-identified appeal in 
triplicate. The fee required for filing the brief should be charged to Deposit No. 22-0185 
maintained in the name of Connolly Bove Lodge & Hutz. 



I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is the International Business Machines 
Corporation, owner of the rights to the above-identified patent application. 

II. RELATED APPEALS AND INTERFERENCES 

There are no known related appeals or interferences which will directly affect or be 
directly affected by or have a bearing on the Board's decision in the pending appeal. 
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III. STATUS OF CLAIMS 

Claims 1-21 are rejected. No claims have been allowed or withdrawn from 
consideration. 

IV. STATUS OF AMENDMENTS 

No amendments were filed subsequent to the final rejection. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The present invention is directed to providing a digital contract that is self-validating and 
which uses existing or future digital certification algorithms. The contract is stored as a single 
file. 

Figure 3 of the application describes the general form of the invention. As described on 
page 4, lines 10-19, a header, rules for describing a valid package, and a body that holds either an 
HTLM or XLM page or other type of data is merged into a single file. The merging step may be 
implemented by zipping the header, rules and body into a single compressed file, using 
conventional compression software such as PKZIP, etc. A signature file is then produced from 
the merged file 2 using a certification algorithm. The signature file is then merged with the 
merged file to produce a header package 3. The header package at this point still does not 
contain a sealing signature so it is not yet valid. In accordance with the rules, a final merged 
package is produced from the merged file and sealing signature. Each merged file also includes 
a unique number. The process of validating the contract requires unzipping the package, viewing 
its contents and seeing if the rules have been followed. 

Figure 7 illustrates how the packages become unzipped and validated. In accordance 
with the description on page 9, lines 21 through page 10, line 24, the package is received and 
unzipped. According to Figure 7, the contract is unzipped, and then the components of the 
package, other than the sealing signature, are unzipped. Components shown in Figure 6 can then 
be produced. The rules are read in step 74 to find the keys required to validate both the entire 
contract and the header package in steps 76 and 78. If the public keys are available locally, they 
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are used to validate the contract and header package. Each sealed package is then validated and 
the body of the text is displayed in Step 82. 

VI. ISSUES 

The issues on appeal are as follows. 

Are claims 1-2, 4-1 1, 13-19 and 21 are patentable under 35 U.S.C. § 103 over Hall et al. 
(U.S. Patent No. 6,138,119) in view of Fischer (U.S. Patent No. 5,214,702)? 

Are claims 3 and 20 patent under 35 U.S.C. § 103 over Hall in view of Fischer in view of 
Ginter (U.S. Patent No. 6,185,683)? 

Is claim 12 patentable under 35 U.S.C. § 103 over Hall in view of Ginter further in view 
of Tedesco et al. (U.S. Patent No. 6,282,523)? 

VII. GROUPING OF THE CLAIMS 

As to the rejection of claim 1-2, 4-11, 13-19 and 21, the claims stand and fall as follows: 

Claims 1 and 4 stand together. 
Claims 5, 6 and 7 stand together. 
Claims 8, 9 and 10 stand together. 
Claims 11 and 12 stand alone. 
Claim 13 stands with claim 8. 
Claims 14 and 15 stand alone. 
Claims 16 and 17 stand together. 
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Claim 18, 19, 20 and 21 stand together. 

As to the rejections of claims 3 and 20, claims 3 and 20 stand and fall together. 
As to the rejection of claim 12, claim 12 stands alone. 

VIII. THE ARGUMENT 

The rejection of claims 1-2, 4-11, 13-19 and 21 under 35 U.S.C. § 103 as being 
unpatentable over Hall et al. (U.S. Patent No. 6,138,1 19) in view of Fischer (U.S. Patent No. 
5,214,702) is in error. 

The primary reference to Hall et al. teaches a data structure identifying the contents of a 
file. The descriptive data structure describes the layout of a write management data structure. 
The descriptive data structure shown as 200 in Figures 2 A and 2B of the reference defines the 
content of a data container 100A. In the example shown in the reference, the descriptive data 
structure 200 defines a number of sections of newspaper style contents 102 such as, for example, 
the headline, the issue date, the lead story, breaking news, etc. The descriptive data structure 
does not contain or specify any particular content of the illustrated newspaper, instead, it merely 
identifies a generic format that a newspaper style publication could use. By abstractly defining 
the data format and other characteristics of newspaper style content, the descriptive data structure 
200 allows easy creation and usage and manipulation of newspaper style content (see in 
particular column 10, lines 45 - column 11, line 10) contained in a data file. 

The primary reference to Hall fails to disclose any contract having rules which are 
contained within a contract. Rejected claim 1, for instance, requires that: 

. . . header package having rules defining sealed packages produced by a sealing 
party, a body containing at least a portion of the content of the contract; and a 
validating signature generated from said rules and said body. . . and a sealing 
signature generated from said header package and said sealed packages according 
to a second key belonging to said sealing party 
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The data structure of the reference does not include any of the foregoing structure. There 
are no rules contained within the body of the data structure, or mentioned in the specification as 
being part of the file which accompanies the data structure. As noted in the Office Action, Hall 
does not teach any validating signature generated from rules according to a first key belonging to 
a validating party, or any sealing signature generated from the header package. 

Hall et al. fails to deal with any of the security issues which are protected by the current 
invention. While the current invention relies on validating and sealing, where validating depends 
on rules embedded in the contract, no such structure is found in Hall et al. 

Turning now to the secondary reference to Fischer, it also fails to disclose the above 
claimed features of applicant's claim 1 . Fischer does not describe any documents which have 
rules defining validating and sealing of a contact package. Fischer appears to be addressing a 
system that allows for the signing of a common certificate by personnel having different security 
levels. In this way, there are hierarchies of signatures which convey authority, restrictions and 
limitations, including monetary authority. Hierarchy of certification authority does not disclose 
the foraging features of applicant's claim 1 described above. 

Claim 2, rejected on the same basis, requires the additional limitation of a unique header 
to identify a type of sealed package, and also validating signature which is generated from the 
rule's body and header of the package. In reviewing the Fischer reference, as well as Hall, none 
of these features appear to be described. 

Rejected claims 8-12 also contain features not disclosed or shown in Hall et al as well as 
in Fischer. For instance, in accordance with claim 8 the header package of a digital file includes 
rules defining sealed packages, a body containing at least a portion of a contract and a validating 
signature. There are no means for reading the rules of a header package, as set forth in claim 8 
and those dependent thereon, 9-10. 
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Claim 16 also requires that the header package have rules which are used to determine 
keys to validate the header package, and a sealed package of the digital file which constitutes a 
contract. It is not seen where either Fischer or Hall have such structure. 

Claim 18 also requires rules to describe a data package, and from the rules, creating a 
data package containing a digital data file, merging the rules and the data package into a merged 
file. In reviewing the cited references, there is no merged file containing a data package with 
rules, which is later merged with a validity signature. 

The rejection of claims 3 and 20 rejected under 35 U.S.C. § 103 as being unpatentable 
over Hall in view of Fischer, further in view of Ginter is in error. As noted in the Office Action, 
Hall does not teach a unique number generated by a sealing party and the sealing signature 
generated from the header package, 

The allegation that Fischer teaches the sealing signature generated from the header 
package, the sealed packages and the unique number is considered to be in error. The hashing 
function provided by Fischer, is for encrypting the data file. While there is an aggregation of 
data which is later hashed to provide an encrypted entity, there isn't the unique number generated 
by a sealing party. 

Ginter describes a system which permits the storage of a secure container in memory 
having a governed item. The governed item is at least in part encrypted. A secure container rule 
is also stored in memory, governing an aspect of access to the use of the first secure container's 
governed item. Hardware is provided which allows access to the secure container using the 
container rule. The containers can be shipped to different locations protected from tampering. 
The protected processing environment allows access to the secured container using the secure 
container rule. 

The foregoing structures allows transmission of a data container which is protected from 
access by someone not having access the secure container rule. The foregoing system fails to 
disclose, as is required by the rejected claims 3 and 20, any sealed package having a unique 
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number generated by a sealing party, and a sealing signature generated from the header package. 
In fact, in reviewing the reference, it is not clear there is any header package which is used to 
contain any rules of the merged file stored in memory. 

As per claim 20, the rules define a sealing signature for the sealed package, which is not 
disclosed in Ginter. 

The rejection of claim 12 under 35 U.S.C. § 103 is also in error. The claim requires that 
a contact management apparatus include 

. . . means for informing users of data files having expiring contracts in the data 
base, a means for deleting the contracts from the data base. 

It is not seen where in any of the applied references these limitations can be found. 

IX. SUMMARY OF ARGUMENT 

The basic requirements of a prima facie case of obviousness are set forth in MPEP 2143. 
This requirement is stated as follows: 

To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there must 
be a reasonable expectation of success. Finally, the prior art reference (or 
references when combined) must teach or suggest all the claim limitations. 

It has been shown by the foregoing that the references as combined do not suggest all the 
claim limitations of the rejected claims. 

Even if all the limitations are found in the prior art would not, in itself, result in a prima 
facie case of obviousness. As set forth in the aforesaid MPEP section, 
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The mere fact that references can be combined or modified does not render the 
resultant combination obvious unless the prior art also suggests the desirability of 
the combination. In re Mills, 916 F.2d 680, 16 USPQ2d 1430 (Fed. Cir. 1990) 
(Claims were directed to an apparatus for producing an aerated cementitious 
composition by drawing air into the cementitious composition by driving the 
output pump at a capacity greater than the feed rate. The prior art reference taught 
that the feed means can be run at a variable speed, however the court found that 
this does not require that the output pump be run at the claimed speed so that air is 
drawn into the mixing chamber and is entrained in the ingredients during 
operation. Although a prior art device "may be capable of being modified to run 
the way the apparatus is claimed, there must be a suggestion or motivation in the 
reference to do so." 916 F.2d at 682, 16 USPQ2d at 1432.). See also In re Fritch, 
972 F.2d 1260, 23 USPQ2d 1780 (Fed. Cir. 1992) (flexible landscape edging 
device which is conformable to a ground surface of varying slope not suggested 
by combination of prior art references). 



The final rejection fails in both respects to establish a prima facie case of obviousness. 
Accordingly, the honorable Board of Patent Appeals and Interferences is requested to reverse the 
decision of the Examiner and remand the case for issuance. 



Respectfully submitted, 



Dated: July 11,2005 




George R. Pettit 



Registration No.: 27,369 
CONNOLLY BOVE LODGE & HUTZ LLP 
1990 M Street, N.W., Suite 800 
Washington, DC 20036-3425 
(202) 331-7111 
(202) 293-6229 (Fax) 
Attorneys for Applicant 
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APPENDIX A 

Claims Involved in the Appeal of Application Serial No, 09/576,223 
Listing of Claims : 

1. (Currently amended) A digital file forming a contract comprising: 

a header package having rules defining sealed packages produced by a sealing party [;] 
A a body containing at least a portion of the content of the contract; and a validating signature 
generated from said rules and said body according to a first key belonging to a validating 
party; and 

a sealing signature generated from said header package and said sealed packages 
according to a second key belonging to said sealing party. 

2. (Original) A digital file forming a contract according to claim 1 wherein said 
header package further comprises a unique header identifying a type of said sealed package and 
wherein said validating signature is generated from said rules, said body and said header. 

3. (Original) A digital file forming a contract according to claim 1 wherein said 
sealed package comprises a unique number generated by said sealing party and said sealing 
signature is generated from said header package, any of said sealed packages and said unique 
number. 

4. (Original) A digital file according to claim 1 wherein said rules define one or 
more unsealed packages to be included in said sealed package, said body comprises a HTML file 
and one of the unsealed packages defined in the rules contains data for a field in the HTML file. 

5. (Original) A digital file according to claim 1 wherein said rules comprise a URL 
corresponding to the location for which each sealed package to be included in the contract can be 
obtained. 



9 



Application No.: 09/576,223 



Docket No.: 20 140-0023 8-US 



6. (Original) A digital contract according to claim 5 wherein said URL is a CGI 
script for commanding a remote server to generate said sealed package. 

7. (Original)A digital contract according to claim 5 wherein said URL identifies 
the location of said sealed package. 

8. (Original) A contract management apparatus for validating a digital file const 
contract, said digital file having a header package which includes rules defining sealed packages, 
a body containing at least a portion of the contract, and a validating signature, comprising: 

means for reading said rules and for identifying a validating party and a sealing party 
which created a sealed file of said contract; 

first means for obtaining a first key belonging to said validating party cooperable with 
said validating signature generated from said rules and body to validate said header package; 

second means for obtaining a second key belonging to said sea cooperable with said 
sealing signature to validate said contract; and 

means for iteratively validating any sealed packages contained in said contract using said 
second key and sealing signature. 

9. (Original) A contract management apparatus as claimed in claim 8 wherein said 
iterative validating means returns any data stored in said sealed packages. 

10. (Original) The contract management apparatus of claim 9 further comprising 
means for displaying said body contents and said returned data. 
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11. (Original) A contract management apparatus for generating a digital file 
constituting a contract comprising: 

means for obtaining a header package for said contract; 

means for reading rules defining sealed data packages, and for identifying a sealing 
party and any sealed packages to be included in said contract; 

means for obtaining said identified sealed packages; 

means for generating a sealing signature from said header package and any of said sealed 
packages according to a first key belonging to said sealing party; and means for assembling said 
header package, sealed packages and said sealing signature into said digital file constituting a 
contract. 

12. (Original) A contract management apparatus comprising: 

means for accepting and securely storing data files constituting contracts in an encrypted 
package database; 

means for backing-up said package database; 

a navigator tool adapted to allow a user access to said stored data files constituting 
said contracts; 

means, responsive to a request for an encrypted package from said data base, for 
transmitting said package to an external entity; 

means for informing users of data files having expiring contracts in said data base; 

and 

means for deleting contracts from said data base. 
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13. (Original) The contract management apparatus of claim 8, including one of a 
smartcard, a personal digital assistant, a personal computer, a terminal or an embedded system. 

14. (Original) A computer product for storing instructions which are executed by a 
computer to validate a digital file having a header package which includes rules defining sealed 
packages, a body containing at least a portion of a contract and a validating signature, 
comprising: 

reading said digital file and identifying a validating party and a sealing party which 
created a sealed package of said contract; 

deriving a first key belonging to a validating party; 

validating said header package using said first key and said validating signature; 
deriving a second key belonging to said sealing 

a sealing signature from said header package; and 

validating said digital file using said second key and said sealing signature. 

15. (Original) The computer product according to claim 14, further comprising 
instructions for deriving said sealing signature from a unique number contained in said header 
package. 

16. (Original) A computer product storing instructions for execution on a computer 
to perform a process to validate a digital file constituting a contract comprising the steps of: a 
header package in said digital file and reading rules contained in said header package; 

determining from said rules keys to validate said header package and a sealed 
package of said digital file constituting said contract; and 

validating each sealed package in said digital file using said keys. 
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17. (Original) The computer product storing instructions for execution on a 
computer according to claim 16, further comprising instructions for performing the additional 
steps of obtaining said keys from a network server identified by said rules. 

18. (Original) A computer product for storing instructions for a computer to execute 
the e steps of: 

storing rules to describe a data package; 

creating from said rules a data package containing a digital data file; merging said 
rules and said data package into a merged file; 

creating a package validity signature from said merged file to prevent unauthorized 
use of said digital file; and 

generating a unique number identifying said digital file; 

merging said package validity signature, said merged file and said unique number; 
creating a sealing signature from said merged files; and 

sealing said merged files with said sealing signature to produce a sealed package. 

19. (Original) A computer product according to claim 18 wherein said rules 
comprises a plurality of elements which point to a location on said computer containing a 
required package. 

20. (Original) The computer product according to claim 19 wherein said rules define 
a sealing signature for said sealed package. 

21 . (Currently amended) [the] The computer product according to claim 18 wherein 
said merged files are compressed as a single file. 
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